1. Field of the Invention
The invention relates to methods for management of certificates in a public key infrastructure. Especially, the invention is related to such a method as specified in the preamble of the independent method claim.
2. Description of Related Art
Public-key infrastructure (PKI) provides means for reliably and securely performing authentication, ensuring message integrity, and providing non-repudiation of transactions in an online environment. PKI is based on the use of public-key (asymmetric) cryptography. In asymmetric cryptography the encryption and decryption of messages is done with different keys. This means that each participating entity (person or device) of the PKI has a set of two keys, a public key and a private key.
Private keys are secret and known only to their owners. Private keys are used for signing and decrypting messages. A common way to ensure the safety of a private key is to store it on a separate piece of hardware (a security token such as a smart card).
Public keys are, as the name implies, public and can be published, for example, in a public directory or on a Web server. Public keys are used for validating signatures and encrypting messages. The two keys are mathematically dependent but the private key cannot be derived from the public key. Furthermore, the two keys possess a distinct quality: what the public key encrypts can only be decrypted by the private key.
Before public-key operations can be made, the public key has to be received securely, so that no one can substitute the genuine key with a tampered one. Certificates can be used for distributing public keys of end entities.
Certificates are digital documents that are used for secure authentication of communicating parties. Certificates are also used for sending the public keys of entities to other entities. A certificate binds identity information about an entity to the entity's public key for a certain validity period. The digital signature of a trusted party makes certificates verifiable with the public key of the trusted party. Certificates can be thought of as analogous to passports that guarantee the identity of their bearers.
To enable wide usage of certificates and interoperable implementations from multiple vendors, certificates have to be based on standards. The most advanced and widespread certificate specifications at the moment are defined by the PKIX Working Group of the IETF (the Internet Engineering Task Force).
End entities are individual users or devices that transact with each other. End entities do not necessarily know each other and they need a way of finding out whether the other party of a transaction is trustworthy.
To enroll in a public-key infrastructure, an end entity needs to request certification for its public key from a certification authority (CA). Certification authorities are entities that vouch for the identity and trustworthiness of the certified end entities. The CA is a trusted third party that the end entities know to be trustworthy. By issuing certificates to the identified end entities, the CA indicates that it vouches for them. Certification authorities can be thought of as being analogous to governments issuing passports for their citizens. A valid certificate signed by a valid CA proves that an end entity is who or what she claims to be.
A certification authority can be operated by an external certification service provider, or even by a government, or the CA can belong to the same organization as the end entities. CAs can also issue certificates to other (sub) CAs. This leads to a tree-like certification hierarchy. The top CA in the tree is called a root CA. FIG. 1 shows a sample certification hierarchy. FIG. 1 shows a root CA 10, sub-CAs 20 directly certified by the root CA, sub-CAs 30 certified by one sub-CA 20, and end entities 40.
In some cases, a CA can delegate the actual identification of end entities as well as some other administrative tasks to a separate entity, the registration authority (RA). The RA performs the identification of the end entities and then signs the end-entity certification requests with its RA private key.
Because the CA has delegated the task of end-entity identification to the RA, the RA signature in the request gives the CA a guarantee of the right for end-entity certification. This allows the CA to operate automatically in online interaction while the local RAs perform the required out-of-band interaction with end entities.
Using local RAs a large geographically or operationally distributed PKI can work in a scalable way, even when the actual certificate issuing is centralized.
Certificate enrollment is an action in which a CA certifies a public key. The actual enrollment process consists of the following steps:    1. Generating a key pair.    2. End entity requesting certification for the public key.    3. CA or RA verifying the identity of the end entity.    4. CA generating a certificate for the end entity and making it available (if the request is approved).
End entities can use standard request formats for requesting certificates from a CA. The CA uses the underlying certificate policy to decide whether to approve the request or not. The policy decision and the approval/denial can be automatic, or the operator of the CA may have to approve the requests manually. If identification of the end entity is needed, the RA may perform this function. If the request is approved, a signed certificate will be issued and delivered to the end entity and possibly also published to a public directory.
Certificate Revocation
Certificates have pre-defined lifetimes, typically lasting from a couple of weeks to several years. If a private key of an end entity is compromised or the right to authenticate with a certificate is lost during the certificate's validity period, the certificate has to be revoked, and all PKI users have to be informed about this in some way. Certificate revocation lists are used for this purpose.
A certificate revocation list (CRL) is a list identifying the revoked certificates and it is signed by a CA. Each CA publishes CRLs on a regular basis. The publishing interval may vary from a couple of minutes to several hours, depending on the security policy of the CA. Verification of a certificate has to include the retrieval of the latest CRL to check that the certificate has not been revoked.
As the certificate revocation lists are updated on a periodic basis, they do not provide real-time status information. If more strict security is required, online certificate status services can be used. In Online Certificate Status Protocol (OCSP) a dedicated OCSP responder entity responds to status requests made by end entities. This kind of function is required for example in a PKI where high-value business transactions are digitally signed.
Certificates and CRLs need to be publicly available for the end entities that perform validation and encryption. A typical solution for publishing certificates is to use an LDAP directory or a Web server as a PKI repository. The Lightweight Directory Access Protocol (LDAP) has become the de facto standard procedure for CRL and certificate distribution.
In typical PKI hierarchies, the main function of the root CA is to certify a number of sub-CAs, which take care of the actual day-to-day work of the PKI. For security reasons, the root CA is often offline, possibly secured in a physically secured area, for example in a bank vault. Such an arrangement minimizes the security risks of the PKI hierarchy. In a large scale PKI the worst-case event in the threat model is the leakage of the root CA private key to an attacker: this would allow the attacker to perform any actions with the authority of the whole PKI hierarchy. Any other key compromise can be compensated for effortlessly and reliably within some predefined time window with the Certificate Revocation List mechanism. Recovering from the root key compromise requires updating the trust anchor at each and every piece of equipment which are part of the PKI, and this task cannot be performed with remote access in a secure manner, so this recovery process is very labor extensive, error-prone and expensive.
Having the root CA offline in a physically secure location prevents the leakage of the root secret key from happening. However, the root CA must anyway produce certificate revocation lists, which in the typical case merely indicate that the certificates of the sub-CAs are still valid. Production of such certificate revocation lists is a chore due to the high security measures: an operator needs to go in person to the root CA computer and manufacture the CRL.